System and Method of Electronic Health Record Permissioning and Monetization

ABSTRACT

A system and method for electronic health record permissioning and monetization that can grant or deny access to patient data and pay one or more entities for access to the data is presented. The present disclosure provides for a system configured to provide a patient the ability to: ‘grant,’ ‘deny,’ ‘update,’ and ‘revoke’ the permission to read data for a specific entity, and specific properties within that entity, from their personal data records (e.g., an electronic health record, a Global Patient Record (GPR), pharmaceutical records, demographic records, financial records, criminal records, or other suitable personal information). A Data-Read-Permission request can be a ‘Property Collection’ (PC) containing specific properties that describe the read permission rights and an amount the Data-Client is willing to offer for the Data-Read-Permission rights. This PC can be written as part of a blockchain transaction (TX1), which can be issued by the Data-Client.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication Ser. No. 63/201,383, filed on Apr. 27, 2021, entitled“ADDRESSABLE UNIVERSAL DATA LOCATOR SYSTEM FOR PROGRAM EXECUTION ANDMETHOD THEREFOR,” U.S. Provisional Patent Application Ser. No.63/201,385, filed on Apr. 27, 2021, entitled “ELECTRONIC HEALTH RECORDPERMISSIONING SYSTEM AND METHOD,” U.S. Provisional Patent ApplicationSer. No. 63/201,388, filed on Apr. 27, 2021, entitled “ELECTRONIC HEALTHRECORD DATA QUALIFICATION SYSTEM AND METHOD,” U.S. Provisional PatentApplication Ser. No. 63/201,387, filed on Apr. 27, 2021, entitled“SERVER PROTOCOL FORMATING SYSTEM AND METHOD,” and U.S. ProvisionalPatent Application Ser. No. 63/201,386, filed on Apr. 27, 2021, entitled“PROPERTY COLLETION SYSTEM AND METHOD,” the contents of which areincorporated herein in their entireties for all purposes.

TECHNICAL FIELD

The present disclosure generally relates to data access permissioning,and more specifically to an electronic health record accesspermissioning and monetization.

BACKGROUND

Traditional patient record systems functions as conventional databaseswith data being stored in database tables associated with a particularpatient. Although modern approaches indicate that the patient's data intheir electronic health record belongs to the patient, there arelimitations to the implementation of this statement. For example, theseconventional databases systems do not empower the patient to controlaccess to it data, nor do these systems provide the granularity ofaccess rights to allow a patient to control exactly which data thesystem provides to third parties. Further, patients are not provided anyincentive to provide their data to, for example, third-party researcherslooking for a large enough sample space to verify their work.

SUMMARY

The present disclosure achieves technical advantages as a system andmethod for electronic health record permissioning and monetization thatcan grant or deny access to patient data and pay one or more entitiesfor access to the data. The present disclosure provides for a systemintegrated into a practical application with meaningful limitations toprovide a patient the ability to ‘grant,’ ‘deny,’ ‘update,’ and ‘revoke’the permission to read data for a specific entity, and specificproperties within that entity, from their personal data records (e.g.,an electronic health record, a Global Patient Record (GPR),pharmaceutical records, demographic records, financial records, criminalrecords, or other suitable personal information). In one embodiment, aData-Client can be a client that is requesting permission to use aPatient's data; a Patient can be a person having data stored in a record(e.g., a patient having an electronic health record stored in the GPR);an EHR-entity can be an entity within the GPR; an EHR-sub-entity can bea sub entity within the GPR (e.g., patient address, patient allergy,etc.); and a Utility can be a system providing the functionalitydisclosed herein.

The present disclosure solves the technological problem of organizing,accessing, and processing patient data stored in memory, as well asprocessing electronic offers for patient data access and facilitating apayment transaction to one or more entities once access is granted. Theelectronic health record permissioning and monetization system solvesthe aforementioned technological problem by providing a blockchain,transaction blockchain API, permissioning module, and a wallet module.Such modules can be implemented in one or more servers coupled to memory(local, network, distributed, or otherwise) using one or more privatekey pairs. Accordingly, the claims herein are necessarily rooted incomputer technology as they overcome a problem arising in the realm ofcomputer database storage, access permissions, encryption, andelectronic payment.

The present disclosure provides a technological solution missing fromconventional systems by providing a system that allows a patient theability to: ‘grant,’ ‘deny,’ and ‘revoke’ the permission to read datafor a specific entity, and specific properties within that entity, fromtheir personal records. In one embodiment, access to the data can befacilitated via public-private key pairs. For example, a Utility canmanage and store a Data-Client's private key. A Data-Read-Permissionrequest can be a ‘Property Collection’ (PC) containing specificproperties that describe the read permission rights and an amount theData-Client is willing to offer for the Data-Read-Permission rights.This PC can be written as part of a blockchain transaction (TX1), whichcan be issued by the Data-Client, as Output-1.1. The TX1 transactionwill have a second output (Output-1.2) that can pay an enticement toconsider offer amount to the electronic currency address of the Patient,from which the Data-Client is seeking permission.

The concepts taught by the present disclosure can be used in anydata-centric industry but are particularly relevant in the healthcareindustry (e.g. clinincal, pharmaceutical, etc.). In another embodiment,National Council for Prescription Drug Programs (NCPDP) promulgatesscript standards that can support prior authorization transactionsbetween a prescriber and a payer. Pursuant to such standards, the GPRcan eliminate the need for these transactions by allowing the Payer toquery the information that it needs directly from the Utility. The datacontained in the GPR will be much richer than the data that can beobtained from the prescriber. The present disclosure provides a modelwhere the Utility can interact with the payer when it runs edits for newprescriptions as part of the prescriber workflow, and when it runs editsfor refills as part of the Pharmacy workflow.

Accordingly, the present disclosure discloses concepts inextricably tiedto computer technology such that the present disclosure provides thetechnological benefit of optimizing database technology to allow apatient the ability to pick which information to share, as well asprovide a technological utility to determine and provide such access.The present disclosure technologically surpasses conventional technologyas, the Utility can prompt a patient to accept or deny a request foraccess and facilitate electronic payment for the access to the patient'sdata.

It is an object of the invention to provide a system for record accesspermissioning and monetization. It is a further object of the inventionto provide a method of record access permissioning and monetization.These and other objects are provided by the present disclosure,including at least the following embodiments.

In one embodiment, a system for record access permissioning andmonetization can include: a blockchain storing one or more data records;and a computer processor operably coupled to the blockchain and capableof executing machine-readable instructions to perform program steps, theprogram steps comprising: receiving a write permission request from aclient indicating types of data to be accessed and an offer amount foraccess; instantiating a first blockchain transaction for requestingaccess permission to a person's record; writing the write permissionrequest to the blockchain as part of the first block chain transaction;transferring the offer amount to a first blockchain address associatedwith the person as part of the first block chain transaction;determining that permission to access a record was granted by the personand instantiating a second blockchain transaction for grantingpermission; instantiating a third blockchain transaction for acceptingpermission; and paying the person the offer amount. Wherein the programsteps further comprise transferring the offer amount having the firstblockchain address to a second blockchain address associated with thepatient as part of the second blockchain transaction. Wherein theprogram steps further comprise transferring a utility amount to ablockchain address associated with a data client as part of the secondblockchain transaction. Wherein the person is paid the offer amount lessthe utility amount. Further comprising a transaction blockchain APIconfigured to provide access to data stored on the blockchain. Whereinthe transaction blockchain API includes an interface that definesinteractions between multiple components. Wherein the write permissionrequest is a Property Collection (PC). Wherein the write permissionrequest Property Collection contains the write permission rights.Wherein the write permission request Property Collection contains theoffer amount. Further comprising a wallet module configured tofacilitate an electronic financial transaction over an encryptednetwork.

In another embodiment, a method of record access permissioning andmonetization can include: receiving a write permission request from aclient indicating types of data to be accessed and an offer amount foraccess; instantiating a first blockchain transaction for requestingaccess permission to a person's record; writing the write permissionrequest to a blockchain as part of the first block chain transaction;transferring the offer amount to a first blockchain address associatedwith the person as part of the first block chain transaction;determining that permission to access a record was granted by the personand instantiating a second blockchain transaction for grantingpermission; instantiating a third blockchain transaction for acceptingpermission; and paying the person the offer amount. Further comprisingtransferring the offer amount having the first blockchain address to asecond blockchain address associated with the patient as part of thesecond blockchain transaction. Further comprising transferring a utilityamount to a blockchain address associated with a data client as part ofthe second blockchain transaction. Wherein the person is paid the offeramount less the utility amount. Further comprising a transactionblockchain

API configured to provide access to data stored on the blockchain.Wherein the transaction blockchain API includes an interface thatdefines interactions between multiple components. Wherein the writepermission request is a Property Collection (PC). Wherein the writepermission request Property Collection contains the write permissionrights. Wherein the write permission request Property Collectioncontains the offer amount. Further comprising a wallet module configuredto facilitate an electronic financial transaction over an encryptednetwork.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be readily understood by the followingdetailed description, taken in conjunction with the accompanyingdrawings that illustrate, by way of example, the principles of thepresent disclosure. The drawings illustrate the design and utility ofone or more exemplary embodiments of the present disclosure, in whichlike elements are referred to by like reference numbers or symbols. Theobjects and elements in the drawings are not necessarily drawn to scale,proportion, or precise positional relationship. Instead, emphasis isfocused on illustrating the principles of the present disclosure.

FIG. 1 illustrates an electronic health record permissioning andmonetization system schematic, in accordance with one or more exemplaryembodiments of the present disclosure;

FIG. 2 illustrates a table listing Global Patient Record Property Pathmapping examples, in accordance with one or more exemplary embodimentsof the present disclosure;

FIG. 3 illustrates a data request-grant-accept schematic, in accordancewith one or more exemplary embodiments of the present disclosure;

FIG. 4 illustrates a data request-deny schematic, in accordance with oneor more exemplary embodiments of the present disclosure;

FIG. 5 illustrates a flowchart exemplifying permission request controllogic, in accordance with one or more exemplary embodiments of thepresent disclosure;

FIG. 6 illustrates a flowchart exemplifying data write request controllogic, in accordance with one or more exemplary embodiments of thepresent disclosure; and

FIG. 7 illustrates an electronic health record data read systemschematic, in accordance with one or more exemplary embodiments of thepresent disclosure.

DETAILED DESCRIPTION

The disclosure presented in the following written description and thevarious features and advantageous details thereof, are explained morefully with reference to the non-limiting examples included in theaccompanying drawings and as detailed in the description. Descriptionsof well-known components have been omitted to not unnecessarily obscurethe principal features described herein. The examples used in thefollowing description are intended to facilitate an understanding of theways in which the disclosure can be implemented and practiced. A personof ordinary skill in the art would read this disclosure to mean that anysuitable combination of the functionality or exemplary embodiments belowcould be combined to achieve the subject matter claimed. The disclosureincludes either a representative number of species falling within thescope of the genus or structural features common to the members of thegenus so that one of ordinary skill in the art can recognize the membersof the genus. Accordingly, these examples should not be construed aslimiting the scope of the claims.

A person of ordinary skill in the art would understand that any systemclaims presented herein encompass all of the elements and limitationsdisclosed therein, and as such, require that each system claim be viewedas a whole. Any reasonably foreseeable items functionally related to theclaims are also relevant. Pursuant to Section 904 of the Manual ofPatent Examination Procedure, the Examiner, after having obtained athorough understanding of the invention disclosed and claimed in thenonprovisional application has searched the prior art as disclosed inpatents and other published documents, i.e., nonpatent literature.Therefore, as evidenced by the issuance of this patent, the prior artfails to disclose or teach the elements and limitations presented in theclaims as enabled by the specification and drawings, such that thepresented claims are patentable under 35 U.S.C. § § 101, 102, 103, and112.

FIG. 1 illustrates an electronic health record permissioning andmonetization system 100 schematic, in accordance with one or moreexemplary embodiments of the present disclosure. The system 100 caninclude one or more servers 102 having one or more processors 104, amemory 130, machine readable instructions 106, including transactionblockchain API 110, a wallet module 112, and a permissioning module 114,among other relevant modules. The server 102 can be operably coupled toone or more clients 150 via a network 140. The clients can be a physicaldevice (e.g., mobile phone, laptop, tablet, desktop computer, wearabledevice, or other suitable device), program, or application. In anotherexemplary embodiment, a client can include a mobile phone having amobile application configured to communicate with the server 102 overthe network 140.

In one embodiment, a transaction blockchain API 110 can be provided bythe system 100 for accessing the blockchain, the transaction blockchainAPI 110 having an interface that defines interactions between multiplecomponents. For example, the blockchain API 110 can define the kinds ofcalls or requests that can be made, how to make them, the data formatsthat should be used, the conventions to follow, and other suitablefunctionality related to a blockchain. In another embodiment, theblockchain API 110 can access and retrieve Property Collections.

In one embodiment, a wallet module 112 can be a service or program thatallows one party to make electronic transactions with another partybartering digital currency units for goods and services. This caninclude purchasing items on-line with a computer or using a smartphoneto purchase something at a store. Money can be deposited in the digitalwallet prior to any transactions or, in other cases, an individual'sbank account can be linked to the digital wallet. Users might also havetheir driver's license, health card, loyalty card(s), and other IDdocuments stored within the wallet. The wallet module 112 can receivedata from a client to effect an electronic funds transfer via ACH, bankwire, PayPal®, Venmo®, crypto currency (e.g., Bitcoin®, Doge®,Litecoin®, etc.). In another embodiment, the wallet module 112 canreceive data related to a user's cryptocurrency address, or the holder'scredentials. For example, the wallet module 112 could store apublic-private key pair, or just a private key for a user of the system.See description related to FIG. 2, below. In another embodiment, thewallet module 112 can provide for a plurality of encryption standard orinterfaces. For example, a Private Key (PK) interface allows theData-Client to be in charge of their own Private Keys; a Token Key (TK)interface could use a simple client-specific access token (GUID); and aClient Certificate (CC) interface could rely on the fact that the clientinstalled a client certificate. In another embodiment, the wallet module112 can be configured to facilitate an electronic financial transactionover the encrypted network 140.

In one embodiment, the permissioning module 114 can provide controllogic to allow a patient the ability to: ‘grant,’ ‘update,’ and ‘revoke’permission to read data for a specific entity (e.g., Data-Client), andspecific properties within that entity, from their personal datarecords, as detailed below.

The aforementioned systems, components, and modules can be communicablycoupled to each other via the network 140, such that data can betransmitted therebetween. The network 140 can be the Internet, intranet,computer bus, or other suitable network. The data transmission can beencrypted, unencrypted, over a VPN tunnel, or other suitablecommunication means. The network 140 can be a WAN, LAN, PAN, or othersuitable network type. The network communication can be encrypted usingPGP, Blowfish, Twofish, AES, 3DES, HTTPS, or other suitable encryption.The system 100 can be configured to provide communication via thevarious systems, components, and modules disclosed herein via anapplication programming interface (API), PCI, PCI-Express, ANSI-X12,Ethernet, Fiber, Wi-Fi, Bluetooth, or other suitable communicationprotocol or medium. Additionally, third party systems and databases 160can be operably coupled to the system components via the network 140.

The data transmitted to and from the components of system 100 (e.g., theserver 102, memory 130, and clients 150), can include any format,including the XPP format disclosed herein, JavaScript Object Notation(JSON), TCP/IP, XML, HTML, ASCII, SMS, CSV, representational statetransfer (REST), or other suitable format. The data transmission caninclude a message, flag, header, header properties, metadata, and/or abody, or be encapsulated and packetized by any suitable format havingsame.

The server(s) 102 can be implemented in hardware, software, or asuitable combination of hardware and software therefor, and may compriseone or more software systems operating on one or more servers, havingone or more processors 104, with access to memory 130. Server(s) 102 caninclude electronic storage, one or more processors, and/or othercomponents. Server(s) 102 can include communication lines, connections,and/or ports to enable the exchange of information via a network 140and/or other computing platforms. Server(s) 102 can also include aplurality of hardware, software, and/or firmware components operatingtogether to provide the functionality attributed herein to server(s)102. For example, server(s) 102 can be implemented by a cloud ofcomputing platforms operating together as server(s) 102, includingSoftware-as-a-Service (SaaS) and Platform-as-a-Service (PaaS)functionality. Additionally, the server(s) 102 can include memory 130,locally attached, network attached, or both.

Memory 130 can comprise electronic storage that can includenon-transitory storage media that electronically stores information. Theelectronic storage media of electronic storage can include one or bothof system storage that can be provided integrally (e.g., substantiallynon-removable) with server(s) 102 and/or removable storage that can beremovably connectable to server(s) 102 via, for example, a port (e.g., aUSB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.).Electronic storage may include one or more of optically readable storagemedia (e.g., optical disks, etc.), magnetically readable storage media(e.g., magnetic tape, magnetic hard drive, floppy drive, etc.),electrical charge-based storage media (e.g., EEPROM, RAM, etc.),solid-state storage media (e.g., flash drive, etc.), and/or otherelectronically readable storage media. Electronic storage may includeone or more virtual storage resources (e.g., cloud storage, a virtualprivate network, and/or other virtual storage resources). The electronicstorage can include a database, or public or private distributed ledger(e.g., blockchain). In one embodiment, memory 130 can be a blockchainimplemented on one or more platforms, including BigChainDB, nChain,Ethereum, Hyperledger, R3, Ripple, EOS, or other suitable blockchainplatform. The blockchain can be a public blockchain (accessible to thegeneral public) or a private blockchain (accessible only by thoseparties credentialed for access). Electronic storage can storemachine-readable instructions 106, software algorithms, control logic,data generated by processor(s), data received from server(s), datareceived from computing platform(s), and/or other data that can enableserver(s) to function as described herein. The electronic storage canalso include third-party databases accessible via the network 140.

Processor(s) 104 can be configured to provide data processingcapabilities in server(s) 102. As such, processor(s) 104 can include oneor more of a digital processor, an analog processor, a digital circuitdesigned to process information, an analog circuit designed to processinformation, a state machine, and/or other mechanisms for electronicallyprocessing information, such as FPGAs or ASICs. The processor(s) 104 canbe a single entity or include a plurality of processing units. Theseprocessing units can be physically located within the same device, orprocessor(s) 104 can represent processing functionality of a pluralityof devices or software functionality operating alone, or in concert.

The processor(s) 104 can be configured to execute machine-readableinstructions 106 or machine learning modules via software, hardware,firmware, some combination of software, hardware, and/or firmware,and/or other mechanisms for configuring processing capabilities onprocessor(s) 104. As used herein, the term “machine-readableinstructions” can refer to any component or set of components thatperform the functionality attributed to the machine-readableinstructions component 106. This can include one or more physicalprocessors 104 during execution of processor-readable instructions, theprocessor-readable instructions, circuitry, hardware, storage media, orany other components.

The server(s) 102 can be configured with machine-readable instructionshaving one or more functional modules. The machine-readable instructions106 can be implemented on one or more servers 102, having one or moreprocessors 104, with access to memory 130. The machine-readableinstructions 106 can be a single networked node, or a machine cluster,which can include a distributed architecture of a plurality of networkednodes. The machine-readable instructions 106 can include control logicfor implementing various functionality, as described in more detailbelow. The machine-readable instructions 106 can include certainfunctionality associated with the system 100. Additionally, themachine-readable instructions 106 can include a smart contract ormulti-signature contract that can process, read, and write data to thememory 130, 3rd party database 160, including a database, distributedledger, or blockchain. In another embodiment, the

Utility can be implemented via the one or more server(s) 102.

FIG. 2 illustrates a table 200 listing Global Patient Record PropertyPath mapping examples, in accordance with one or more exemplaryembodiments of the present disclosure. The table 200 lists a GPP example202, an associated derivation path 204, and a description 206. In oneembodiment, a GPR Entity can be data, encapsulated within a PropertyCollection, within a Patient's GPR. The address to the entity can bedescribed by a Global Patient Record Property Path (GPP). This path canbe relative to a specific patient. In another embodiment, a hierarchicaldeterministic (HD) wallet can use derivation paths to specify an addressto a keypair within the hierarchy. An HD wallet can be patient specificand used to manage a patient's public and private keys. As its namesuggests there is one root key that can have child keys, with each childkey having their own children. This can keep repeating into a largehierarchy. In one embodiment, an HD Wallet can automatically generate ahierarchical tree-like structure of private/public addresses (or keys),thereby addressing the problem of the user having to generate them ontheir own. In another embodiment, a GPP can be mapped to a derivationpath. This mapping can associate a GPP with a keypair. As shown in table200, the GPP 202 can be mapped to an HD Wallet Derivation Path 204.

In another embodiment, the Utility can implement a hierarchicaldeterministic wallet, in combination with Metanet technology to createthe structure and storage for a Patient's GPR. For example, a Metanetcan be a global protocol and framework for structuring and facilitatingthe on-chain internet for a BitcoinSV blockchain. In particular, theMetanet can be a protocol for creating transactions that allow on-chaindata to form a graph structure, which can be interpreted and usedoff-chain by wallets, browsers, and applications. This metanet, coupledwith a built-in permissioning system according to the presentdisclosure, can use the stable, underlying protocol of a BSV blockchainto ensure users and content creators are in complete control and owntheir data.

FIG. 3 illustrates a data request-grant-accept schematic 300, inaccordance with one or more exemplary embodiments of the presentdisclosure. In one embodiment, the Patient has the ability to ‘grant’permission to read data for a specific entity, and specific propertieswithin that entity, from their GPR. For example, if the Patient decidesto grant the permission, the permissioning module can process data asfollows: generation of a Data-Client Request Permission blockchaintransaction (TX1) 302 having an Output-1.1 and Output-1.2; generation ofa Patient Grant Permission blockchain transaction (TX2) 304 having anOutput-2.1 and Output-2.2; and generation of a Data-Client AcceptPermission blockchain transaction (TX3) 306 having an Output-3.1.

In another embodiment, a Data-Read-Permission request can be a ‘PropertyCollection’ (PC) containing specific properties that describe the readpermission rights and an amount the Data-Client is willing to offer forthe Data-Read-Permission rights. This PC can be written as part of aData-Client Request Permission blockchain transaction (TX1) 302, whichcan be issued by the Data-Client, as Output-1.1. The TX1 transaction 302can have a second output (Output-1.2) that can pays an enticement toconsider offer amount to the blockchain address of the Patient, fromwhich the Data-Client is seeking permission. In another embodiment, ifthe Patient decides to grant the permission, the permissioning modulecan issue another blockchain transaction (TX2) 304, with two outputs,that spends Output-1.2 of TX1 302 and pays a nominal amount to theData-Client or Utility through Output-2.2 of TX2 304. The Output-2.1 canbe a data output, which contains a Property Collection (PC) withproperty values that specify that the permission has been granted. TheTX2 transaction 304 can also send money to another blockchain address ofthe Patient (e.g., spending the enticement to consider amount). TheData-Client can then write another blockchain transaction (TX3) 306,which can spend Ouput-2.2 of TX2 and pay the Patient the offer amountfor the Data-Read-Permission. In another embodiment, the transaction TX3can verify a contract granting access and paying the enticement amount.For example, these blockchain transactions can represent theData-Read-Permission Contract between the Data-Client and the Patient.This contract will be verified when the Data-Client issues a request forthe data (via Output-3.1) for which the Data-Read-Permission wasgranted. In another embodiment, one or more of the followingReadPermission Property Collection attributes can be used during thisprocess:

Name Type Description RID String A GUID that will be used as the readpermission ID. Type String “r”-Read PublicKey byte array A public keyrepresenting an ID for the patient. The patient's root public key is notexposed. GPP string The GPP of the entity in which the permissionapplies. GPP_Properties Property A collection of PropertyPermissionstructures that Collection define the specific properties of an entitythat are Array accessible. GPP_Children Boolean A Boolean value thatindicates if the permission is being granted to all child nodes of theGPP. FromDateTime DateTime A DateTime value used to indicate the minimumDate and Time of when the data starts. If this field is not present,then all data from beginning of data until ToDateTime will be used.ToDateTime DateTime A DateTime value used to indicate the maximum Dateand Time of the data of when the date ends. If this property is notpresent, then all data FromDateTime will be used. ReadDataFunctionString The name of a data retrieval function used to extract the GPREntity(s) and package it for the Data-Client. ReadDataQualifier StringThe name of a qualifier used to filter data as it is retrieved by theDataFunction. DurationUnits string A code that indicates what theduration unit is. For example: ‘day’, ‘single event’, etc. DurationInteger The number of units the permission is being granted for.Description String A detailed description of the permission.

In another embodiment, one or more of the following PropertyPermissionProperty Collection attributes can be used during this process:

Name Type Description Include Boolean A Boolean value, which indicatesif the property should be included (True) or excluded (False) GPP stringThe GPP of a property within the Entity to which the permissions apply.

READ PERMISSION EXAMPLE: Drug XYZ and Heart Rate Data

In one exemplary embodiment, a patient grants the following read accessto Drug Company XYZ for Drug XYZ:

-   -   1. Patients birthdate    -   2. Patients zip    -   3. Patients gender    -   4. Patients allergies    -   5. Patients genomics    -   6. Patients Prescriptions/transactions for Drug XYZ        -   a. Once the transactions for Drug XYZ are known, the            ReadDataFunction can determine the While_On_Drug_XYZ (Date            range), which will be used within other GPP data queries.    -   7. Patients Exercise Data        -   a. While_On_Drug_XYZ (+/−X Days)        -   b. Data            -   i. Start Date/Time            -   ii. End Date/Time            -   iii. Description (i.e. running, walking, lifting, yoga)    -   8. Patients Apple watch Heart Rate data        -   a. While_On_Drug_XYZ (+/−X Days)        -   b. Data (i.e. predefined function)            -   i. 10-minute intervals            -   ii. Mean            -   iii. Low            -   iv. High

Such permissioning can be more than just giving access to data items. Itcan be giving access to different types of data based on the date rangeof prescription transactions. Because of the complexity of defining thesub queries (e.g., heart rate data, etc.) as independent queries, a setof predefined functions that understand how to retrieve the data ofinterest can be implemented. Once a specific function is instantiated,the system can reference the function as part of the permission. Thesefunctions can be stored on the blockchain (e.g., in a catalog) with adescription of what they do.

FIG. 4 illustrates a data request-deny schematic 400, in accordance withone or more exemplary embodiments of the present disclosure. In oneembodiment, the Patient has the ability to ‘deny’ permission to readdata for a specific entity, and specific properties within that entity,from their GPR. For example, if the Patient decides to deny thepermission, the permissioning module can process data as follows:generation of a Data-Client Request Permission blockchain transaction(TX1) 302 having an Output-1.1 and Output-1.2; and generation of aPatient Deny Permission blockchain transaction (TX2) 402 having anOutput-2.1 and Output-2.2.

In another embodiment, if the Patient decides to deny the permission,the permissioning module can issue another blockchain transaction (TX2)402, with two outputs, which spends Output-1.2 of TX1 302. TheOutput-2.1 can be a data output, which contains a Property Collection(PC) with property values that specify that the permission has beendenied. The Output-2.2 can send the change of the transaction or anotification thereof to the Patient.

FIG. 5 illustrates a flowchart exemplifying permission request processflow control logic 500, in accordance with one or more exemplaryembodiments of the present disclosure. The request process flow controllogic 500 can be implemented as an algorithm on a server 102, a machinelearning module, a client 150, a memory 130, a combination of one ormore of the aforementioned components, or other suitable system. Therequest process flow control logic 500 can be achieved with software,hardware, an application programming interface (API), a networkconnection, a network transfer protocol, HTML, DHTML, JavaScript, Dojo,Ruby, Rails, other suitable applications, or a suitable combinationthereof.

The request process flow control logic 500 can leverage the ability of acomputer platform to spawn multiple processes and threads by processingdata simultaneously. The speed and efficiency of the request processflow control logic 500 can be greatly improved by instantiating morethan one process to implement a permission request. However, one skilledin the art of programming will appreciate that use of a singleprocessing thread may also be utilized and is within the scope of thepresent disclosure.

Since patients may not interact directly with companies interested inacquiring their data, there can be a mechanism that can allow a requestto be sent to the patient with a clear understanding of the following:

-   -   What the data will be used for.    -   The date range, if applicable, for the request.    -   The data elements for which permission is being requested.    -   The process of collecting the data.    -   The date range, the permission will be valid.

When a company such as Drug Company XYZ, wants to gain access to data,they can submit a request, provide a description, and determine if apredefined Permission Template already exists for the type of request.

The request process flow control logic 500 of the present embodimentbegins at step 502, where the control logic 500 can generate or receivea patient data access request. In one embodiment, the request can befrom a client. In another embodiment, the request can include requestdata having one or more fields, parameters, characteristics, ormetadata. For example, the patient access request can include healthcareparameters, pharmaceutical parameters, clinical parameters, demographicparameters, time parameters, volume parameters, frequency parameters, orother relevant parameters. In another exemplary embodiment, the requestcan include a command such as upload, download, save, retrieve, or othersuitable command. The control logic 500 then proceeds to step 504.

At step 504, the control logic 500 can determine whether a requesttemplate exists. In one embodiment, the request template can beretrieved from the blockchain. For example, the request template can bestored in a catalog of templates (e.g., Read Permission Request Catalog)stored in the blockchain. If a request template exists, the controllogic 500 proceeds to step 508. If the request template does not exist,the control logic proceeds to step 506.

At step 506, the control logic 500 can generate a permission templateincluding at least a portion of the data from the request. In oneembodiment, the template can have a standardized set of fields orparameters based upon the request. In another embodiment, the templatecan transform the request into a standardized format processable by thesystem. In another embodiment, a permission template can be generatedlisting the requirements of the request. In another embodiment, therequirements can be written and packaged as a data retrieval functionand installed on a decrypt server. This function can be added to the newtemplate. The finalized permission request template can be stored in arequest catalog (e.g., on the blockchain). The control logic 500 thenproceeds to step 508.

At step 508, the control logic 500 can populate request template withrequest parameters. In one embodiment, the control logic 500 can parsethe request to populate one or more corresponding fields in thetemplate. For example, the template can have a standardized set offields or parameters based upon the request. In another embodiment, thecontrol logic can use the template to transform the request into astandardized format processable by the system. The control logic 500then proceeds to step 510.

At step 510, control logic 500 can query a database for patientsmatching the request parameters. In one embodiment the control logic 500can generate a query response with a listing of patients matching thequery. The control logic 500 then proceeds to step 512.

At step 512, the control logic 500 can filter a database query responseto identify patients matching additional parameters or narrow the listof patients according to the additional parameters. In one embodiment,not enough patients are returned matching the query so the control logic500 can widen the search by adding additional parameters to the query.For example the thresholds for the number of query returns and theadditional parameters can be included in the request. In anotherembodiment, too many patients are returned matching the query so thecontrol logic 500 can narrow the search by adding additional parametersto the query. The control logic 500 then proceeds to step 514.

At step 514, the control logic 500 can populate a request templatehaving a matching patient unique ID (e.g., public key). In oneembodiment, The template can be populated with the relevant propertiesfor the request. The GPR Database (e.g., BC RAW DB) can be queried toidentify the patients that match the requirements of the request. Inanother embodiment, for each patient that qualifies: The template willbe populated with the Public Key of the patient and the‘ReadPermissionRequest’ can be transmitted to the patient. The controllogic then proceeds to step 516.

At step 516, the control logic 500 can transmit a populated requesttemplate to matching patients. In one embodiment, the request templatecan identify the types of data for which access is requested. In anotherembodiment, the request template can indicate an offer amount for accessto the requested data. The control logic 500 then terminates or awaits anew request and can repeat the aforementioned steps.

In one embodiment, a GPR data read permission request can include:

Property Name Type Description RID String A GUID that will be used asthe ID for the read permission request. Description String A Descriptionof the data that is being requested. Duration_Unit String A code thatindicates the requested duration unit. For example: ‘day’, ‘singleevent’, etc. DurationUnits string A code that indicates what theduration unit is. For example: ‘day’, ‘single event’, etc.

In one embodiment, a GPR data read permission response can include:

Property Example Value GPP Patient.Prescriptions Grant read access tothe patient's prescriptions. GPP_Filter Drug_XYZ The name of a ‘filter’that limits the ‘result set’ of the GPP to only be prescriptions thatwere written for Drug XYZ. GPP_Filter_Result_Set drug_xyz_rs The name ofthe result set

In one embodiment, the control logic 500 can have built-in functions.For example, the control logic 500 can assign a name to the ‘resultset,’ having the ‘drug_xyz_rs.values,’ which can be the collections ofRxTx collections and the drug. In another embodiment, control logic 500can execute a collection of functions that can determine, for example,the date range—given a list of prescription transactions. The result setcan be a predefined or dynamic PC. The control logic can execute SQLcommands to filter the results set, for example: selectmin(date_of_service) from ‘result set’ and select max(date_of_service)from ‘result set.’ For example, the GPP can be the address of the data;the GPP_Filter can be a predefined filter that can consider all PCs ofGPP and produce a result set. The result set functions can be acollection of filter creation functions. Given a result set, the controllogic 500 can run a function that can create a Filter, that can be usedto ‘filter’ other data sets. In another embodiment, the control logic500 can define functions that return a dynamic filter and store them onthe blockchain. For example, FilterWhile_On_Drug_XYZ=DetermineMinMax(result_set).

FIG. 6 illustrates a flowchart exemplifying data write request processflow control logic 600, in accordance with one or more exemplaryembodiments of the present disclosure. The data write request processflow control logic 600 can be implemented as an algorithm on a server102, a machine learning module, a client 150, a memory 130, acombination of one or more of the aforementioned components, or othersuitable system. The data write request process flow control logic 600can be achieved with software, hardware, an application programminginterface (API), a network connection, a network transfer protocol,HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications,or a suitable combination thereof.

The data write request process flow control logic 600 can leverage theability of a computer platform to spawn multiple processes and threadsby processing data simultaneously. The speed and efficiency of the datawrite request process flow control logic 600 can be greatly improved byinstantiating more than one process to implement a data write request.However, one skilled in the art of programming will appreciate that useof a single processing thread may also be utilized and is within thescope of the present disclosure.

In one embodiment, a Data-Write-Permission request can be a ‘PropertyCollection’ (PC) containing specific properties that describe the writepermission rights and an amount the Data-Client is willing to offer forthe Data-write-Permission rights. In one embodiment, this PC can bewritten as part of a blockchain transaction (TX1) (e.g., Bitcoin-SV),which can be issued by the Data-Client, as Output-1.1. The TX1transaction can have a second output (Output-1.2) that can pay anenticement to consider offer amount to the blockchain address of thePatient, from which the Data-Client is seeking permission. If thePatient decides to grant the permission, the Patient can issue anotherblockchain transaction (TX2) that can spend Output-1.2 of TX1 and pay anominal amount to the Data-Client through Output-2.2. The TX2transaction can also send money to another blockchain address of thePatient (e.g., spending the enticement to consider amount). TheData-Client can then write another blockchain transaction (TX3), whichcan spend Ouput-2.2 of TX2 and pay the Patient the offer amount for theData-Read-Permission. These blockchain transactions can represent theData-Write-Permission Contract between the Data-Client and the Patient.This contract can be verified when the Data-Client issues a data writerequest associated with the Data-Write-Permission.

The request process flow control logic 600 of the present embodimentbegins at step 602, where the control logic 600 can receive a writepermission request indicating an offer amount. In one embodiment, therequest can be from a client. In another embodiment, the request caninclude request data having one or more fields, parameters,characteristics, or metadata. For example, the patient access requestcan include healthcare parameters, pharmaceutical parameters, clinicalparameters, demographic parameters, time parameters, volume parameters,frequency parameters, or other relevant parameters. In another exemplaryembodiment, the request can include a command such as upload, download,save, retrieve, or other suitable command. The control logic 600 thenproceeds to step 604.

Add step 604, the control logic 600 can instantiate a first blockchaintransaction for requesting permission. The control logic 600. Thenproceeds to step 606.

At step 606, the control logic 600 can write the write permissionrequest to a blockchain as part of the first blockchain transaction. Thecontrol logic then proceeds to step 608.

Add steps 608, the control logic 600 can transfer the offer amount to afirst blockchain address associated with the patient as part of thefirst blockchain transaction. In one embodiment, a patient can have oneor more blockchain addresses associated with the patient. For example,each blockchain entry having a unique ID associated with the patient canhave an address, that address can be associated with the patient via theunique ID. The control logic 600 then proceeds to step 610.

At step 610, the control logic 600 can determine whether permission wasgranted. If permission was not granted, the control logic 600 proceedsto step 612. If permission was granted, the control logic 600 proceedsto step 614.

At step 612, the control logic 600 can terminate the first blockchaintransaction. The control logic 600 can then terminate or await a newrequest and repeat the aforementioned steps.

At step 614, the control logic 600 can instantiate a second blockchaintransaction for granting permission. The control logic 600 then proceedsto step 616.

At step 616, the control logic 600 can transfer the transferred offeramount to a second blockchain address associated with the patient aspart. Of the second blockchain transaction. The control logic 600 thenproceeds to step 618.

At step 618, the control logic 600 can transfer a utility amount to ablockchain address associated with a data client or utility as part ofthe second blockchain transaction. The control logic 600 then proceedsto Step 620.

At step 620, control logic 600 can instantiate a third blockchaintransaction for accepting permission. The control logic 600 thenproceeds to step 622.

At step 622, the control logic 600 can pay the data client or theutility the utility amount and pay the patient the offer amount less theutility amount. The control logic 600 can then terminate or await a newrequest and repeat the aforementioned steps.

In another embodiment, a Write Permission Property Collection caninclude the following:

Name Type Description Type String “w”-Read PublicKey byte array A publickey representing an ID for the patient. The patient's root public key isnot exposed. GPP string The GPP of the entity in which the permissionapplies. GPP_Children Boolean A Boolean value that indicates if thepermission is being granted to all child nodes of the GPP. FromDateTimeDateTime A DateTime value used to indicate the minimum Date and Time ofwhen the write permission starts. If this field is not present, thenwrite permission starts immediately. ToDateTime DateTime A DateTimevalue used to indicate the maximum Date and Time of the write permissionis effective. If this property is not present the write permission isindefinite. DurationUnits string A code that indicates what the durationunit is. For example: ‘day’, ‘single event’, etc. Duration Integer Thenumber of units the permission is being granted for. Description StringA detailed description of the permission.

FIG. 7 illustrates an electronic health record data read system 700schematic, in accordance with one or more exemplary embodiments of thepresent disclosure. The electronic health record data read system 700can include a data client 702, a decrypt server 706, a GPR database 708,a blockchain reader 712, and a blockchain 710. In one embodiment, thedata client 702 can be a client 150, the decrypt server can be a server102, the GPR database can be a memory 130, the block chain reader 712can be a transaction blockchain API 110, and the blockchain can be amemory 130. For example, a Data-Client can be a software component thatrequests data to be queried and returned based on a preexisting andvalid read permission contract; a Read Request can be a message that canrequest GPR entity data to be queried and returned; a Read Response canbe the requested GPR decrypted data; a Decrypt Server can be responsiblefor looking up the predefined permission request by querying the BC-RAWDB for the entities covered by a preexisting and valid read permissioncontract; a BC-RAW DB can be a database that contains GPR Entitydata—the data within this database can be encrypted; a BC-Reader canread blocks from the Blockchain, processes each transaction within theblock and determine if the transaction contains GPR data—if thetransaction does contain GPR data, the data can be loaded into theBC-Raw DB; and a BSV BC can be the Blockchain.

Since at least a portion of the data within the GPR can be encrypted itcan remain encrypted until it is requested. The decrypt server can beused to decrypt data from the GPR database (e.g., BC-Raw DB). Thedecrypt server can be encrypt and decrypt data using PGP, Blowfish,Twofish, AES, 3DES, HTTPS, or other suitable encryption standards. Thedata in the BC-Raw DB 708 may have been previously read from theBlockchain 710 (e.g., BSV BC).

In another embodiment, when the Decrypt Server 706 receives a ReadRequest 704, it determines if the sender is authorized to submit therequest. For example, the authorization can be performed by checking adigital signature that may be provided with the request. In anotherembodiment, once the request has been authorized, the Decrypt Server 706queries the BC-RAW DB 708 for the GPR entities that were defined by apreexisting and valid permission contract. In another embodiment, oncethe entities have been retrieved, each entity can be decrypted using thePrivate Key of the node where it was stored in the blockchain 710 (e.g.,Metanet Tree within the Bitcoin SV blockchain). Once the entity has beendecrypted, the serialized byte array can be returned to the client inthe Decrypt Response.

Although one or more embodiments may reference a patient, the presentdisclosure applies to any type of entity, whether a person, patient,customer, company, or other suitable entity capable of having datastored in a record associated with that entity. Similarly, althoughcertain embodiments may reference electronic health records, thesystems, methods, and concepts disclosed herein are equally applicableto any storage system or record type.

Persons skilled in the art will readily understand that advantages andobjectives described above would not be possible without the particularcombination of computer hardware and other structural components andmechanisms assembled in this inventive system and described herein.Additionally, the algorithms, methods, and processes disclosed hereinimprove and transform any general-purpose computer or processordisclosed in this specification and drawings into a special purposecomputer programmed to perform the disclosed algorithms, methods, andprocesses to achieve the aforementioned functionality, advantages, andobjectives. It will be further understood that a variety of programmingtools, known to persons skilled in the art, are available for generatingand implementing the features and operations described in the foregoing.Moreover, the particular choice of programming tool(s) may be governedby the specific objectives and constraints placed on the implementationselected for realizing the concepts set forth herein and in the appendedclaims.

The description in this patent document should not be read as implyingthat any particular element, step, or function can be an essential orcritical element that must be included in the claim scope. Also, none ofthe claims can be intended to invoke 35 U.S.C. § 112(f) with respect toany of the appended claims or claim elements unless the exact words“means for” or “step for” are explicitly used in the particular claim,followed by a participle phrase identifying a function. Use of termssuch as (but not limited to) “mechanism,” “module,” “device,” “unit,”“component,” “element,” “member,” “apparatus,” “machine,” “system,”“processor,” “processing device,” or “controller” within a claim can beunderstood and intended to refer to structures known to those skilled inthe relevant art, as further modified or enhanced by the features of theclaims themselves, and can be not intended to invoke 35 U.S.C. § 112(f).Even under the broadest reasonable interpretation, in light of thisparagraph of this specification, the claims are not intended to invoke35 U.S.C. § 112(f) absent the specific language described above.

The disclosure may be embodied in other specific forms without departingfrom the spirit or essential characteristics thereof. For example, eachof the new structures described herein, may be modified to suitparticular local variations or requirements while retaining their basicconfigurations or structural relationships with each other or whileperforming the same or similar functions described herein. The presentembodiments are therefore to be considered in all respects asillustrative and not restrictive. Accordingly, the scope of theinventions can be established by the appended claims rather than by theforegoing description. All changes which come within the meaning andrange of equivalency of the claims are therefore intended to be embracedtherein. Further, the individual elements of the claims are notwell-understood, routine, or conventional. Instead, the claims aredirected to the unconventional inventive concept described in thespecification.

What is claimed is:
 1. A system for record access permissioning andmonetization, comprising: a blockchain storing one or more data records;and a computer processor operably coupled to the blockchain and capableof executing machine-readable instructions to perform program steps, theprogram steps comprising: receiving a write permission request from aclient indicating types of data to be accessed and an offer amount foraccess; instantiating a first blockchain transaction for requestingaccess permission to a person's record; writing the write permissionrequest to the blockchain as part of the first block chain transaction;transferring the offer amount to a first blockchain address associatedwith the person as part of the first block chain transaction;determining that permission to access a record was granted by the personand instantiating a second blockchain transaction for grantingpermission; instantiating a third blockchain transaction for acceptingpermission; and paying the person the offer amount.
 2. The system ofclaim 1, wherein the program steps further comprise transferring theoffer amount having the first blockchain address to a second blockchainaddress associated with the patient as part of the second blockchaintransaction.
 3. The system of claim 1, wherein the program steps furthercomprise transferring a utility amount to a blockchain addressassociated with a data client as part of the second blockchaintransaction.
 4. The system of claim 3, wherein the person is paid theoffer amount less the utility amount.
 5. The system of claim 1, furthercomprising a transaction blockchain API configured to provide access todata stored on the blockchain.
 6. The system of claim 5, wherein thetransaction blockchain API includes an interface that definesinteractions between multiple components.
 7. The system of claim 1,wherein the write permission request is a Property Collection (PC). 8.The system of claim 7, wherein the write permission request PropertyCollection contains the write permission rights.
 9. The system of claim7, wherein the write permission request Property Collection contains theoffer amount.
 10. The system of claim 1, further comprising a walletmodule configured to facilitate an electronic financial transaction overan encrypted network.
 11. A method of record access permissioning andmonetization, comprising: receiving a write permission request from aclient indicating types of data to be accessed and an offer amount foraccess; instantiating a first blockchain transaction for requestingaccess permission to a person's record; writing the write permissionrequest to a blockchain as part of the first block chain transaction;transferring the offer amount to a first blockchain address associatedwith the person as part of the first block chain transaction;determining that permission to access a record was granted by the personand instantiating a second blockchain transaction for grantingpermission; instantiating a third blockchain transaction for acceptingpermission; and paying the person the offer amount.
 12. The method ofclaim 11, further comprising transferring the offer amount having thefirst blockchain address to a second blockchain address associated withthe patient as part of the second blockchain transaction.
 13. The methodof claim 11, further comprising transferring a utility amount to ablockchain address associated with a data client as part of the secondblockchain transaction.
 14. The method of claim 13, wherein the personis paid the offer amount less the utility amount.
 15. The method ofclaim 11, further comprising a transaction blockchain API configured toprovide access to data stored on the blockchain.
 16. The method of claim15, wherein the transaction blockchain API includes an interface thatdefines interactions between multiple components.
 17. The method ofclaim 11, wherein the write permission request is a Property Collection(PC).
 18. The method of claim 17, wherein the write permission requestProperty Collection contains the write permission rights.
 19. The methodof claim 17, wherein the write permission request Property Collectioncontains the offer amount.
 20. The method of claim 11, furthercomprising a wallet module configured to facilitate an electronicfinancial transaction over an encrypted network.